Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate PipelineRun.Spec.ServiceAccountNames 🦌 #3028

Conversation

vdemeester
Copy link
Member

@vdemeester vdemeester commented Jul 29, 2020

Changes

PipelineRun.Spec.TaskRunSpecs already allows to specify a
ServiceAccountName for a specific task. This marks
PipelineRun.Spec.ServiceAccountNames as deprecated and to be removed
in about 9 months.

This also make sure PipelineRun.Spec.ServiceAccountNames are not ignored.

Fixes #2614

Signed-off-by: Vincent Demeester [email protected]

/cc @bobcatfish @sbwsg @afrittoli @jlpettersson

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

  • Includes tests (if functionality changed/added)
  • Includes docs (if user facing)
  • Commit messages follow commit message best practices
  • Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

PipelineRun.Spec.ServiceAccountNames is being deprecated in favor of PipelineRun.Spec.TaskRunSpec[].ServiceAccountName

@tekton-robot tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jul 29, 2020
@vdemeester
Copy link
Member Author

/kind cleanup

@tekton-robot tekton-robot added the kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. label Jul 29, 2020
@vdemeester vdemeester force-pushed the 2614-serviceAccountNames-deprecation branch from 2994728 to 2354446 Compare July 29, 2020 09:30
`PipelineRun.Spec.TaskRunSpecs` already allows to specify a
`ServiceAccountName` for a specific task. This marks
`PipelineRun.Spec.ServiceAccountNames` as deprecated and to be removed
in about 9 months.

This also make sure `PipelineRun.Spec.ServiceAccountNames` are not ignored.

Signed-off-by: Vincent Demeester <[email protected]>
@vdemeester vdemeester force-pushed the 2614-serviceAccountNames-deprecation branch from 2354446 to e6fe3bf Compare July 29, 2020 09:37
@vdemeester vdemeester added this to the Pipelines v0.15 milestone Jul 29, 2020
@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/pipelinerun/pipelinerun.go 86.0% 85.6% -0.4
pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go 92.6% 90.2% -2.5

Copy link
Member

@jlpettersson jlpettersson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

for _, taskrunSpec := range pr.Spec.TaskRunSpecs {
if _, ok := pipelineTasks[taskrunSpec.PipelineTaskName]; !ok {
return fmt.Errorf("PipelineRun's taskrunSpecs defined wrong taskName: %q, does not exist in Pipeline", taskrunSpec.PipelineTaskName)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to validate taskNames!

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 29, 2020
@dlorenc
Copy link
Contributor

dlorenc commented Jul 29, 2020

nice! lgtm, this is an API change though so I think it needs to be approved by "more than 50% of owners", right?

@vdemeester
Copy link
Member Author

nice! lgtm, this is an API change though so I think it needs to be approved by "more than 50% of owners", right?

So… nothing in the API changes (aka no field is added or removed), we are just marking a field for deprecation (that we should have done when TaskRunSpecs was added ServiceAccountName support) ; so I am not fully sure if it meets the API changes requirement 😅. That said, I prefer to be safe than sorry 😝

/cc @bobcatfish @dibyom @afrittoli @imjasonh

@tekton-robot tekton-robot requested review from dibyom and imjasonh July 29, 2020 13:49
@bobcatfish
Copy link
Collaborator

I agree with @dlorenc 's interpretation: i think that approving and merging this PR would be our intent to have a backwards incompatible change, even if we don't make that change in this PR.

I approve - i wonder if it might be worth taking some time to examine taskRunSpecs a bit more closely, it feels like we haven't though through that area of the API carefully (for example not noticing that it repeated the info in serviceAccountNames) but that might just be me being like "i wasnt part of this so i dont like it" so 🤷‍♀️ . I agree that having both doesn't make sense.

@vdemeester
Copy link
Member Author

I agree with @dlorenc 's interpretation: i think that approving and merging this PR would be our intent to have a backwards incompatible change, even if we don't make that change in this PR.

I approve - i wonder if it might be worth taking some time to examine taskRunSpecs a bit more closely, it feels like we haven't though through that area of the API carefully (for example not noticing that it repeated the info in serviceAccountNames) but that might just be me being like "i wasnt part of this so i dont like it" so woman_shrugging . I agree that having both doesn't make sense.

So the gist behind TaskRunSpecs is that, we started with serviceAccountNames to specify serviceAccountName per tasks (in the pipeline). Then there was a need for doing the same for podTemplate. It made more sense to group those than having a field for each with the same "structure" (task, type).

@@ -366,14 +366,23 @@ func (c *Reconciler) reconcile(ctx context.Context, pr *v1beta1.PipelineRun) err
return controller.NewPermanentError(err)
}

// Ensure that the ServiceAccountNames defined correct.
// Ensure that the ServiceAccountNames defined are correct.
// This is "deprecated".
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: why in quotes?

@afrittoli
Copy link
Member

I approve of this change.
Counting @vdemeester and myself, the change is approved by 50% of the owners, which is not enough to meet the rule yet.
I think it's not a big deal if this shifts to v0.16.0 so I'll stick to the rule and not merge this for now.
@vdemeester you'll have to update the deprecation notices from v0.15.0 to v0.16.0.

@pritidesai @sbwsg FYI

@ghost
Copy link

ghost commented Aug 3, 2020

Yup, I also approve.

@dlorenc
Copy link
Contributor

dlorenc commented Aug 3, 2020

Looks like we're at quorom now!

/approve

@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dlorenc, jlpettersson

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 3, 2020
@tekton-robot tekton-robot merged commit 28d1347 into tektoncd:master Aug 3, 2020
@vdemeester vdemeester deleted the 2614-serviceAccountNames-deprecation branch August 4, 2020 08:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Duplicate ways to specify ServiceAccountName for tasks in a PipelineRun
6 participants